1. Field of the Invention
This invention relates to virtual machines.
2. Related Art
The interpretive-execution facility of Enterprise Systems Architecture/370(TM) (ESA/370(TM)) provides the START INTERPRETIVE EXECUTION (SIE) instruction for the execution of virtual machines. Initially created for virtualizing either System/370 or 370-XA architectures, and later for virtualizing ESA/370 architecture, SIE provides capabilities for a number of specialized performance environments. This comprehensive set of capabilities in the architecture serves as the platform for VM/ESA's ability to provide functions in virtual machines for end users and system servers. A virtual machine (VM) system with guest architecture emulation is described in detail in U.S. Pat. No. 4,456,954 to Bullions, III et. al. and assigned to the same assignee as the present invention.
VM/ESA uses the ESA/370(TM) Interpretive-Execution Facility to assign to the processor much of the burden of managing the virtual-machine environment. Within this document, the term GUEST refers to any virtual, or "interpreted," machine. The control program directly managing the real machine, and thus responsible for establishing the guest execution environment, is referred to as the HOST. The host issues a single instruction, START INTERPRETIVE EXECUTION (SIE), which places the machine in interpretive-execution mode. In this mode, the machine provides the functions of a selected architecture. This architecture may also be available on a real machine, such as System/370, 370-XA, or ESA/370, or may be an architecture provided exclusively in the virtual machine environment such as the ESA/XC architecture. The functions provided by the machine include privileged instructions, problem-program instructions, address translation, interruption handling, and timing among other things, and I/O in some cases. The machine is said to INTERPRET the functions that it executes in the context of the virtual machine. Similarly, many types of interruptions are interpreted, presented directly to the guest by the machine, without host intervention.
In the virtual-machine environment the guest program perceives the full complement of functions defined for the designated architecture. Most of those functions are provided in the machine in the form of the interpretive execution facility. However, there remain functions, that are not provided by the interpretive-execution facility. These are provided by the underlying host control program, called CP for VM/ESA, through a process called simulation. Except for performance, simulation endeavors to "execute" guest functions transparently, so that whether a function is performed by the machine or the host is indistinguishable to the guest program.
The operand of the SIE instruction is a control block called the state description. The state description contains information relevant to the current state of the guest. When execution of SIE ends, the guest Program Status Word (PSW) and other information which depicts the state of the guest is saved in the state description before control is returned to the host. This information is used and modified by the host during simulation, and is later used to resume execution of the guest. Other information in the state description determines the mode and other environmental conditions in which the guest is to execute.
While in interpretive-execution mode, a virtual machine is constrained to some portion of the real-machine resources. These resources are allocated by the host. Thus guest storage is confined either to some portion of hot-real storage or to host-virtual-address spaces controlled by the host system. Host enabled and disabled states are generally undisturbed by execution of the guest. Host timing facilities are also undisturbed; instead, a second set is provided for the guest. One complete and logically separate set of control registers is maintained by the machine for use by the host and another is maintained for use by the guest. This protection of the host from interference by the guest permits the host to meet its primary responsibility of efficiently parceling out the real resources to multiple guests. It also prevents one guest from interfering with another guest.
Fundamental to any architecture is the method for providing access to storage. ESA/370 defines three levels of storage address. Dynamic Address Translation (DAT) transforms a virtual address into a real address. Prefixing is performed on a real address to yield an absolute address, which designates a location in physical storage. Prefixing uses the contents of the CPU's prefix register to "swap" addresses 0-4095 with another address range, so that each CPU can have access to different low storage for interruption parameters, save areas, and processor specific data.
The method for representing guest-absolute storage is a key consideration for virtual machines. Two basic storage modes are provided by the interpretive-execution architecture: preferred-storage mode and pageable-storage mode. In preferred-storage mode, a contiguous block is assigned to the guest, whereas in pageable-storage mode, dynamic address translation (DAT) at the host level is used to map guest main storage.
A location in virtual storage is defined by a virtual address and the address space in which it is contained. The segment-table designation, which is usually located in a control register, corresponds to an address space. The Dynamic-Address-Translation (DAT) process converts a virtual address to a real address, by means of a selected entry in the segment table, and a selected entry in the page table designated by that segment-table entry. The result is the real address of the storage frame corresponding to the virtual address.
A virtual-machine environment may call for application of DAT twice: first at the guest level, to translate a guest virtual address through guest-managed translation tables into a guest real address, and then, for a pageable guest, at the host level, to translate the corresponding host-virtual address to a host-real address.
In VM/370, the need to effect two levels of address translation for pageable virtual machines with guest DAT active was satisfied by means of "shadow" translation tables, segment and page tables built by the host reflecting the combined results of the two mappings. The increased addressing capacity offered by 370-XA threatened to limit the performance achievable through "shadow" mechanisms, because of the danger of "sparseness" of address references over the much larger two-gigabyte address range, because of the larger translation-table sizes, and because of the cost to maintain and ensure the integrity of the shadow tables.
These concerns led IBM to forsake shadow tables for general use in interpretive execution, in favor of performing both levels of translation in the machine. This improved method and means of translation is described in detail in U.S. Pat. No. 4,695,950 to Brandt et. al., which is assigned to the same assignee as the present invention. As with the native architecture, translation-lookaside buffers are built into the machine to retain the results of previous address translations, and so speed the resolution of addresses in pages referenced repeatedly.
The native ESA/370 architecture introduced access registers and linkage stacks. These facilities are described, for example, in U.S. Pat. No. 4,945,480 to Clark et al. and assigned to the same assignee as the present invention. The interpretive execution facility makes both of these facilities of the ESA/370 architecture available to guests if they are available on the underlying real machine.
The host is responsible for loading the guest's access register values before starting interpretive execution, and saving them (and restoring host values) afterward. Thereafter, access register translation is performed by the interpretive execution facility at the guest level, before the application of guest DAT. Unlike dynamic address translation, before the present invention, access register translation (ART) was not performed at the host level by the interpretive execution facility.
The conventional address translation process for the class of ESA/370 DAT-on guests is shown in FIG. 1. Guest access register translation is applied to a guest virtual address 112 to derive a guest virtual address 114. Guest dynamic address translation is then applied to the guest virtual address 114 to derive a guest real address 116. The guest real address is then processed in the same manner as a DAT-off pageable mode guest (as will be described by reference to FIG. 3) to derive a host absolute address 110. The application of access register translation at the guest level enables the use of access registers for memory sharing between tasks operating within the context of a single virtual machine, but it does not allow host-controlled memory sharing between tasks operating in different virtual machines.
In ESA/370, as in System/370 and 370-XA, the base (B) or register (R) portion of an instruction operand designates a general register. In ESA/370 access-register mode, the same-numbered access register is used during Access-Register Translation (ART) to determine the address space of the operand.
Access-register translation uses an access-list-entry token (ALET) in an access register to locate an access-list entry (ALE) which, in turn, is used to locate the segment-table designation to be used during DAT. The segment-table designation corresponds to an address space.
On an operating system like MVS/ESA(TM), the access registers bring a powerful capability: that of addressing data in multiple address spaces in a sequence of instructions, or even in the same instruction, without control-program intervention. MVS/ESA runs programs with Dynamic Address Translation (DAT) enabled, so that the logical addresses each program references are translated through MVS-maintained constructs into real addresses. Faults result in interruptions to MVS, which then pages in the required data. In this environment, access registers offer several benefits:
Programs can directly manipulate much larger amounts of data.
The full instruction set can be used to operate on data in any of a great number of spaces.
Individual programs can share data subject to the owning program's permission, enforced by the operating system.
Programs can segregate data more logically, keeping like or related data in the same space, to facilitate controlled sharing.
The capabilities which access registers offer are attractive. However, the structure of VM is substantially different from that of MVS. VM has always been a "two-tiered" system. As illustrated in FIG. 2, the Control Program (CP) component 132 of VM creates a separate virtual machine 126-130 for each logged-on user. Application programs run under the Conversational Monitor System (CMS), a single-user "second level" operating system running within the user's virtual machine. A CMS virtual machine can support an interactive user, a system server like a file-system manager or network spooler, or a private server such as an Advanced Program to Program Communication (APPC) peer.
Under the VM system, CP manages system resources, establishes the virtual machine environment, and enforces isolation among the simulated machines. CMS assumes the responsibility for application services such as file and program management, and for interacting with the end user. CP applies authorization controls to bound the user's (virtual machine's) activities. CP uses architectural facilities like DAT and guest extent checking, as described above, to keep these boundaries secure. Conversely, CMS enforces almost no controls over the application program: Programs under CMS run in (virtual) supervisor state. CMS makes some use of storage keys to prevent inadvertent damage, but a "willful" program can always circumvent CMS and assume control of the virtual machine. According to traditional VM philosophy, each user's machine is his own. CP ensures that an errant or malicious program's acts are confined to the virtual machine in which it is run.
Moreover, CMS manages only the linear storage of a single virtual machine; that is, CMS runs without enabling DAT itself, and does no virtual storage management (paging or swapping). These tasks are CP's domain. CP builds DAT tables and uses them to define each address space representing a virtual machine's storage. These host-virtual address spaces, defined by host DAT tables, map guest-absolute storage.
CMS can be considered to be a member of a general class of guests that runs in pageable mode, without DAT enabled. The address translation process for this class of guests is illustrated in FIG. 3. When a CMS guest needs to access the system memory, it uses a "guest real address" 102. To the "guest real address", guest prefixing is applied to derive a "guest absolute address" 104. A main storage origin (MSO) value is added to the guest absolute address, and the resulting "host virtual address" 106 is then verified to ensure that it is within the main storage extent (MSE). Once the "host virtual address" has been generated and verified, host dynamic address translation is applied to form a "host real address" 108. Host prefixing is then applied to establish a "host absolute address" 110. It is the "host absolute address" that references a physical location in the system memory.
Because of the structure of the CMS class of guests, access register translation, as provided by the interpretive execution facility before the present invention, is not usable by this class of guests. Prior to the present invention, in order to use ART, a guest under VM/ESA CP needed to enable DAT, since ART applies only to virtual addresses. Further, prior to the present invention, the application of access register translation within the VM/ESA environment was limited to use within the address spaces of individual guests who maintained their own access register translation tables and guest ART control registers.
3. Documents Incorporated by Reference
The following patents are incorporated by reference, in their entireties, as if printed in full below U.S. Pat. No. 4,945,480 to Clark et. al., entitled "DATA DOMAIN SWITCHING ON PROGRAM ADDRESS SPACE SWITCHING AND RETURN"; U.S. Pat. No. 4,456,954 to Bullions, III et al., entitled "VIRTUAL MACHINE SYSTEM WITH GUEST ARCHITECTURE EMULATION USING HARDWARE TLB's FOR PLURAL LEVEL ADDRESS TRANSLATIONS"; U.S. Pat. No. 4,695,950 to Brandt et al., entitled "FAST TWO-LEVEL DYNAMIC ADDRESS TRANSLATION METHOD AND MEANS"; and U.S. Pat. No. 4,779,188 to Gum at. al., entitled "SELECTIVE GUEST SYSTEM PURGE CONTROL".